Add docs on 'Create app flavors for Windows and Linux' - #13736

Markdown list nesting looks off and will likely break the numbering in rendering.

Item 1 (line 80) uses 1. + 4-space continuation indent, but items at lines 87 and 126 use 1. with no indented body, and the <Tabs> blocks between them start at column 0. That takes the following content out of the list context, so the ordered list restarts rather than continuing 1 → 2 → 3.

Same pattern in the "Create distinct window titles" section (lines 271/280 and 299/308).

Compare with flavors-ios.md, which keeps everything under a consistent 4-space continuation indent. Worth previewing the built page to confirm the step numbers render as 1/2/3.

The Linux mechanism here is correct — unlike the Windows tab. GTK takes narrow const char* strings, so the preprocessor define works directly with no conversion. flutter_flavorizr does exactly this, and its example project builds and runs with it.

Two adjustments to match what actually works:

1. Placement. target_compile_definitions(${BINARY_NAME} …) needs the target to exist, so it must come after add_executable(${BINARY_NAME} …). flutter_flavorizr anchors on the existing APPLICATION_ID define, which is already correctly positioned:

# Add preprocessor definitions for the application ID.
add_definitions(-DAPPLICATION_ID="${APPLICATION_ID}")

if(DEFINED FLUTTER_APP_FLAVOR AND NOT FLUTTER_APP_FLAVOR STREQUAL "")
  add_definitions(-DFLUTTER_APP_FLAVOR="${FLUTTER_APP_FLAVOR}")
endif()

Placing the new block right after the APPLICATION_ID line is an easy instruction to follow and is guaranteed to be in scope.

2. my_application.cc snippet doesn't match the file it's editing. The generated my_application_activate passes the title as a string literal in two places. The snippet introduces a title variable but shows the if (use_header_bar) block dedented to column 0, whereas in the real file it's indented two spaces inside the function — so this can't be pasted as-is.

The working shape, which keeps the diff to the existing code minimal:

  const gchar* window_title = "flavors_example";
#ifdef FLUTTER_APP_FLAVOR
  if (g_strcmp0(FLUTTER_APP_FLAVOR, "staging") == 0) {
    window_title = "Staging App";
  } else if (g_strcmp0(FLUTTER_APP_FLAVOR, "production") == 0) {
    window_title = "Production App";
  }
#endif

then replace the two hardcoded literals with window_title:

    gtk_header_bar_set_title(header_bar, window_title);
    ...
    gtk_window_set_title(window, window_title);

Using g_strcmp0 rather than string concatenation also lets each flavor have a fully custom title instead of AppName (flavor), which is closer to what people actually want from flavors.

Blocking — this section isn't implementable as written.

Two problems:

1. The snippet targets windows/CMakeLists.txt, where FLUTTER_APP_FLAVOR is still undefined (same scope issue as the earlier section). if(FLUTTER_APP_FLAVOR STREQUAL "staging") on an undefined variable is always false, so APP_ICON_NAME silently falls through to else().

2. Step 3 — "Configure windows/runner/Runner.rc or your CMake target to use APP_ICON_NAME" — is the entire difficulty, and it's left as an exercise. Runner.rc is a resource script; it cannot read CMake variables. There is no way to complete this step from what the page provides.

flutter_flavorizr handles this with the same configure_file pass proposed in my comment on the window-title section — one mechanism covering icon, title, and PE metadata. Extend that block in windows/runner/CMakeLists.txt, before add_executable:

configure_file(
  "${CMAKE_CURRENT_SOURCE_DIR}/Runner.rc.in"
  "${CMAKE_CURRENT_SOURCE_DIR}/Runner.rc"
  @ONLY
)

Rename Runner.rc to Runner.rc.in and parameterize it — these are the exact substitutions its example project ships:

IDI_APP_ICON            ICON                    "resources\\@RUNNER_APP_ICON@"

VALUE "FileDescription", "@WINDOW_TITLE@" "\0"
VALUE "ProductName",     "@WINDOW_TITLE@" "\0"

with the per-flavor .ico files sitting in windows/runner/resources/ alongside the default app_icon.ico.

Same caveat as before: Runner.rc becomes a generated file, so it should be gitignored while Runner.rc.in is committed.

This section is prose-only, and step 3 — "Update linux/CMakeLists.txt to install the correct .desktop file and icon" — is where all the actual work lives. A reader can't act on it.

It's also genuinely harder than the Windows case: on Linux the icon isn't embedded in the binary, so it depends on .desktop entries, the icon theme layout, and the packaging format (snap/deb/flatpak).

I'd suggest cutting these three steps and linking to Build and release a Linux app instead, noting that per-flavor icons are a packaging concern rather than a flavor concern. Shipping three non-actionable bullets sets readers up to fail — and I'd rather not propose a concrete recipe here, since I don't have a verified working example to base one on.

Two additions worth making somewhere in this section:

1. --flavor also works with flutter test and flutter drive on desktop, not just run/build. The Linux PR touched commands/test.dart for exactly this, and both devicelab tasks (flavors_test_linux.dart, flavors_test_windows.dart) exercise createFlavorsTest() / createIntegrationTestFlavorsTest(). Readers wiring flavors into CI will look for this.

2. Existing projects shouldn't need to regenerate anything. Neither desktop flavor PR modified the windows.tmpl / linux.tmpl templates, so --flavor works on any existing project as-is — no flutter create . re-run, no template migration. That's a genuinely reassuring detail and cheap to state.

This sentence sits inside the Linux tab, so readers on the Windows tab never see it — even though the Windows snippet above uses the same <flavor_name> placeholder.

Move it out of the <Tabs> block so it applies to both.